enable_reasoning toggle silently has no effect on MiniMax

The adapter routes reasoning through OpenAICompatibleLLMParameters.validate(), which sends reasoning_effort in extra_body. MiniMax's OpenAI-compatible API does not recognise reasoning_effort; it exposes deep thinking via a thinking: {type: "adaptive"} field instead (MiniMax docs). A user who turns this toggle on will have their temperature stripped from the request (potentially changing generation behaviour) while MiniMax silently ignores the unknown reasoning_effort key — no actual reasoning is activated. Is there a plan to map enable_reasoning → thinking: {type: "adaptive"} in MiniMax's request body, or should the enable_reasoning section be removed from minimax.json until that mapping is implemented?

This is a comment left during a code review.
Path: unstract/sdk1/src/unstract/sdk1/adapters/llm1/static/minimax.json
Line: 59-64

Comment:
**`enable_reasoning` toggle silently has no effect on MiniMax**

The adapter routes reasoning through `OpenAICompatibleLLMParameters.validate()`, which sends `reasoning_effort` in `extra_body`. MiniMax's OpenAI-compatible API does not recognise `reasoning_effort`; it exposes deep thinking via a `thinking: {type: "adaptive"}` field instead ([MiniMax docs](https://platform.minimax.io/docs/guides/text-generation)). A user who turns this toggle on will have their `temperature` stripped from the request (potentially changing generation behaviour) while MiniMax silently ignores the unknown `reasoning_effort` key — no actual reasoning is activated. Is there a plan to map `enable_reasoning` → `thinking: {type: "adaptive"}` in MiniMax's request body, or should the `enable_reasoning` section be removed from `minimax.json` until that mapping is implemented?

How can I resolve this? If you propose a fix, please make it concise.

Confirmed — this is a real issue, not just a doc mismatch.

The reasoning path in OpenAICompatibleLLMParameters.validate() (base1.py) does two things when enable_reasoning is on: it puts reasoning_effort into extra_body and pops temperature (validated.pop("temperature", None)). MiniMax's OpenAI-compatible endpoint doesn't recognise reasoning_effort — it gates deep thinking via thinking: {type: "adaptive"} — so the key is silently ignored while the user's temperature is stripped. The toggle activates no reasoning but changes generation behaviour.

Severity is bounded to the opt-in case: it only fires if a user flips the toggle. It won't auto-enable, since _is_openai_reasoning_model matches only o1|o3|o4|gpt-5, not MiniMax-M3.

Fix: dropping the enable_reasoning block (and its allOf conditional) from minimax.json for now, since the shared OpenAI-compatible validate path has no way to emit MiniMax's thinking field. A proper enable_reasoning → thinking:{type:"adaptive"} mapping would be a follow-up in the validate layer.

Routing through custom_openai/ silently zeroes out cost tracking for MiniMax.

_validate_branded_openai_compatible delegates to OpenAICompatibleLLMParameters.validate(), whose validate_model() unconditionally prepends custom_openai/. cost_model is only populated when the endpoint is OpenAI's own (base1.py:483), so it stays unset here, and audit.py:98 ends up calling cost_per_token(model="custom_openai/MiniMax-M3") — which raises, gets swallowed by the bare except, and records cost_in_dollars = 0.0 at debug level.

LiteLLM already ships a native MiniMax provider, and it prices M3:

litellm.get_llm_provider("minimax/MiniMax-M3")  -> ('MiniMax-M3', 'minimax', None, None)

cost_per_token("custom_openai/MiniMax-M3") -> raises        => cost = 0.0
cost_per_token("minimax/MiniMax-M3")       -> $0.30 / $1.20 per 1M tokens

So every MiniMax token would bill as $0 in usage tracking, silently.

This is why OpenRouterLLMParameters extends BaseChatCompletionParameters instead of OpenAICompatibleLLMParameters — its own docstring says so: "Routed through LiteLLM's native openrouter/ provider so per-token costs resolve and reasoning params map without provider-specific workarounds." MiniMax should follow OpenRouter's template, not NVIDIA Build's.

Worth noting NVIDIA Build's custom_openai/ routing is correct for NVIDIA — LiteLLM prices zero nvidia_nim/ chat models (3 entries, all rerankers, all $0.0), so there's nothing to forfeit there. That reason doesn't carry over to MiniMax.

Bonus: MinimaxChatConfig.get_api_base() already returns https://api.minimax.io/v1, so going native lets you drop the hardcoded _MINIMAX_API_BASE constant entirely.

The shipped MiniMax.png is the OpenRouter logo.

frontend/public/icons/adapter-icons/MiniMax.png is byte-for-byte identical to OpenRouter.png:

0980b0d3102c84da9d332862c563c44f  MiniMax.png
0980b0d3102c84da9d332862c563c44f  OpenRouter.png
676be9d2fc5cec78d5be80af03eb9fd4  NvidiaBuild.png

Both 29953 bytes. Rendering it confirms it's the OpenRouter fork-arrow mark. NvidiaBuild.png differs, so this isn't a shared-placeholder convention — it looks like the icon was copied along with the adapter template and never swapped.

Users would see OpenRouter's branding on the MiniMax card in the adapter picker. Needs the real MiniMax logo.